Dev Console Aliases - #3841

What

Adds @osdk/aliases, a new package holding the alias runtime, and a browser-safe entry point so Developer Console apps can read installer-supplied configuration.

Why

Custom aliases let an app author declare env-var-style config that a Marketplace installer fills in at install time. Two problems with hosting that in @osdk/functions:

1. @osdk/functions peer-depends on @osdk/client, so a browser app reading a JSON file inherited a client version floor. This is not theoretical: it failed npm install in a Developer Console app's build with ERESOLVE.
2. Aliases are meant to span Functions, transforms, Slate, and Developer Console. Living inside one runtime's package misrepresents that.

@osdk/aliases has no dependencies on @osdk/client or @osdk/functions, so neither problem can recur by construction.

Public API

import { Aliases } from "@osdk/aliases/experimental";

await Aliases.initAliases();                      // once, before first read
const apiBaseUrl = Aliases.custom("apiBaseUrl");  // synchronous afterwards

Node code (Functions) keeps using the filesystem runtime, unchanged:

import { Aliases } from "@osdk/functions";   // or "@osdk/aliases/node"
Aliases.custom("myAlias");

Entry points:

The browser API sits behind experimental so the import path states its stability at every call site, matching @osdk/client, @osdk/react, and @osdk/react-components.

Resolution behavior

initAliases() fetches once, caches, and then serves custom() synchronously. Browsers have no synchronous network read, which is why an explicit init exists rather than matching Functions' fully synchronous shape.

Two files can supply values:

Callers do not choose. The deployment config is tried first and the declaration file is used only when it appears absent, meaning a 404 or a 200 carrying an HTML document (single-page-app hosts rewrite unknown paths to index.html). Any other failure throws instead of falling back, because on an installed site both files are served and treating an error as absence would silently serve the author's defaults in place of the installer's values. Absence detection is a heuristic and is documented as one: a proxy or authentication page can also be a 200 with markup.

Compatibility

@osdk/functions re-exports the Node runtime through a local facade at src/aliases/index.ts, so its public Aliases namespace is unchanged. The facade is a local module with explicit named re-exports for two API Extractor limitations, both documented in the file: it cannot process export * as ns from an external package, and it rejects a namespace whose target uses export *.

etc/functions.report.api.md is updated to reflect that the namespace members now resolve from @osdk/aliases/node.

Testing

pnpm turbo test           --filter=@osdk/aliases     # 99 tests
pnpm turbo typecheck      --filter=@osdk/aliases --filter=@osdk/functions
pnpm turbo transpileTypes --filter=@osdk/aliases --filter=@osdk/functions
pnpm turbo check-api      --filter=@osdk/functions
pnpm --dir packages/aliases lint
npx mrl check

transpileTypes is listed separately because typecheck runs with --emitDeclarationOnly false and so does not exercise --isolatedDeclarations; a declaration-emit error can pass typecheck and still fail the build.

Verified end to end against a Foundry stack:

• Declared two aliases in an app's public/resources.json, deployed the site, packaged it as a Marketplace product, and installed it with overrides. The running site reads the installer's values rather than the declared defaults.
• Upgraded the installation to a new product version. The installer's values persist, which is the reason the alias input-shape id excludes the application version.

Not yet verified: packaging an application that declares no aliases.